Actionable comments posted: 1

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/actions/integration-db/action.yml:
- Around line 83-99: Validate the PostgREST port in the supabase branch before
constructing or exporting pgrest_url. Capture the result of port_of postgrest
3000, fail with a clear error and docker compose status output when it is empty,
and preserve the existing pg_port validation and URL behavior for valid ports.

Overview

Fixes a genuinely nasty CI failure mode: the three integration workflows funnelled into two ref-unscoped concurrency groups (integration-live-db-<db>), and GitHub Actions allows only one in-progress + one pending per group — so a third contender is cancelled, not queued. A cancelled job's check goes absent rather than red, and since main isn't branch-protected, the lost signal blocks nothing (it bit the db=supabase leg of #712 — the exact variant that PR exists to fix). This removes the contention instead of serialising it: a new integration-db composite action gives each job a unique compose project name + ephemeral host ports, so nothing is shared and nothing needs to queue.

Well-reasoned and cleanly executed. LGTM / approvable — details below; no blocking issues.

What I verified

• Isolation mechanism is correct. The compose files gain ports: "${CS_PG_PORTS:-55432:5432}" — unset keeps the fixed local-dev mapping; set to a bare container port (CS_PG_PORTS=5432) makes Compose publish to an ephemeral host port. The action reads the assigned port back via docker compose port, and the project name (cs-it-<run>-<attempt>-<job>-<variant>, lowercased/sanitised to [a-z0-9_-], always starting with c) is unique per job and attempt, so a re-run can't adopt a prior attempt's containers.
• Fail-closed port readback. port_of treats empty stdout (what docker compose port prints, at exit 0, for an unbound port) as the failure signal — errors, dumps ps, returns 1 — and each port is a bare x="$(port_of …)" assignment so set -euo pipefail fails the step unambiguously (correctly avoiding the local x=$(…) exit-status mask). The comment notes this closes a real review-found asymmetry where an unbound PostgREST would have silently produced http://localhost:.
• Teardown is correctly guarded. CS_COMPOSE_PROJECT/CS_COMPOSE_FILE are written to $GITHUB_ENV before docker compose up, so even a failed up (e.g. --wait timeout) still tears down the right project; and if: always() && env.CS_COMPOSE_PROJECT != '' skips teardown cleanly when the stack never came up (no confusing -p "" error masking the real failure). Removing the pre-up blanket down -v is right — with no concurrency group, another job's stack may be live on the runner, so a blanket prune would now be actively unsafe.
• Script-injection-safe. inputs.db and github.job reach the shell via env: (DB_VARIANT/JOB_ID), never templated into the run body; matrix.db is a static [postgres, supabase]. No user-controlled value interpolates into a shell script.
• Governance gate is real. /.github/actions/ added to CODEOWNERS (composite actions run arbitrary steps with the workflow's secrets — same blast radius as /.github/workflows/) and asserted in supply-chain.e2e.test.ts; the PR states the assertion was verified to fail without the rule (non-vacuous). No changeset is correct — repo tooling only, no published surface.
• The runner-only path is proven. The docker compose port readback can only run on a real runner, and all five of this PR's own integration jobs pass (Drizzle postgres+supabase, Supabase, prisma-next postgres+supabase) — so the added action executed end-to-end and worked.

Notes — non-blocking

1. Increased concurrent load on the shared ZeroKMS workspace. The old Supabase workflow comment cited "a live-DB job that shares one ZeroKMS workspace should finish, not be interrupted" as part of the queueing rationale. With the groups gone, all three workflows × both variants can now run fully concurrently against the same CS_WORKSPACE_CRN. This looks safe — the per-job DB is where suite state lives and it's now isolated, and I grepped the integration suites for workspace-global assertions (listClients/listKeys/key counts) and found none — but worth a moment's confirmation that no suite depends on workspace-exclusive ZeroKMS state, since that's the one shared resource the isolation doesn't cover.
2. No reaper for hard-killed leaks. A SIGKILL'd job skips even the always() teardown, and the pre-up prune is (correctly) gone, so on a reused runner a leaked stack has nothing to clean it up. Harmless if the Blacksmith runners are ephemeral (fresh VM per job) — worth a one-line confirmation, else a periodic prune of cs-it-* projects older than N hours would backstop it.

Verdict

A real, well-diagnosed fix for a silent-signal-loss failure mode, implemented with genuinely careful shell (fail-closed readback, guarded teardown, injection-safe env passing) and validated by its own green integration run. Both notes are non-blocking confirmations. I'd approve this — say the word and I'll flip it to a formal approval.

These changes look good, thanks for the fix @coderdan.